Certificate Authority Hierarchy

Who should read these docs?

This page is for platform/infra engineers maintaining the iot-device-management Terraform, or anyone responding to a CA-related incident or planning a CA rotation.

CA Hierarchy Overview

Every environment's issuing CA is a subordinate of a parent (root/intermediate) CA in AWS Certificate Manager Private CA. All parent CAs live in the same tooling account (266735834856); what differs is how many stages each parent is shared out to. For the Manufacturing/Shared hierarchy:

• Shared lower-environment parent (4363d5eb...) is shared to dev, test, and staging via AWS Resource Access Manager (RAM), which grants each of those accounts permission to sign against a CA owned by the tooling account. Each of those three stages creates its own subordinate issuing CA signed by this same parent, and each stage's subordinate is its own distinct Terraform-managed resource with its own ARN, even though they share the same parent/signer.
• Prod's Manufacturing parent (9742888d...) is RAM-shared only to prod. No other stage references it.
• Staging and prod also each have a separate, dedicated Operational CA (89980222... and 8f07cfdb... respectively, each likewise RAM-shared to just its one stage). See the ARN reference table below for details; omitted from the diagram to keep it focused on the Manufacturing/Shared side this doc is primarily about.

Because dev and test each own a distinct subordinate CA object (separate Terraform state, separate ARNs), reissuing or rotating one stage's CA certificate has no effect on another stage's CA, even though they share the same parent signer.

CA ARN Reference

Stage	Region(s) actually deployed	Config key	Parent CA ARN	Parent also used by
dev	us-east-1 (only region that exists in config)	Shared	4363d5eb...	test, staging
test	us-east-1 (CA lives here), registered into IoT Core in eu-central-1 and ap-southeast-2 too	Shared	4363d5eb...	dev, staging
staging	us-east-1 only	Manufacturing / Operational	4363d5eb... (Manufacturing) / 89980222... (Operational)	dev, test (Manufacturing only)
prod	us-east-1 only	Manufacturing / Operational	9742888d... (Manufacturing) / 8f07cfdb... (Operational)	no one, both dedicated to prod

Test spans all three regions. The ACM PCA CA object only exists in us-east-1, but its certificate is registered in IoT Core in eu-central-1 and ap-southeast-2 too, via manufacturing_ca_arn_override/operating_ca_arn_override in those regions' tfvars pointing at the same us-east-1 CA rather than provisioning a new one.

Staging and prod are us-east-1-only today. staging/eu-central-1.tfvars, staging/ap-southeast-2.tfvars, and prod's equivalents exist in the repo but nothing is deployed under them, and build-pipeline/main.tf's deployment_environments lists regions = ["us-east-1"] only for every stage. Treat those files as prepared-but-inactive until that changes; the staging pair in particular would fail to apply as-is (empty cert_authority_config with no override means the CA-selection fallback logic has nothing to resolve to).

Why dev/test use a single "Shared" CA

Private CAs are expensive to run, so dev and test collapse the Manufacturing and Operational roles into a single CA instead of paying for two per environment. Staging and prod keep them separate.

Terraform's variables.tf validation enforces this split: type = "shared" is disallowed in cert_authority_config when stage is prod or staging, so only dev and test are allowed to use one CA for both roles.

The CA-selection logic falls back to Shared whenever a stage doesn't define a dedicated key:

• Bootstrap-cert issuance uses the Manufacturing CA if one is configured, else falls back to Shared.
• Operational-cert issuance uses the Operational CA if one is configured, else falls back to Shared.

Because dev/test's Shared CA has to serve both roles, its own validity has to comfortably outlive the longest-lived cert it issues (the 22-year bootstrap cert), so it takes the Manufacturing-equivalent validity value (23 years), not the Operational-equivalent value (5 years).

Validity Windows

	Validity
Bootstrap cert	22 years
Operational cert	1 year
Shared CA's own validity	23 years

Terraform Impact

bootstrap_cert_validity/operational_cert_validity are plain Lambda environment variables. Updating them is an in-place change with no resource replacement. cert_authority_config.<key>.validity_value, however, feeds into the CA's own signing certificate, which ACM PCA has no update API for. Changing it forces Terraform to replace that certificate (and its IoT Core registration), though the CA object itself (keypair/ARN) is untouched and already-issued device certs stay valid.

CA Expiry

CA	Expires
Shared / Manufacturing CA	2049-11-10
Operational CA (staging/prod)	2035-11-10

CA rotation automation is in progress. Until it lands, rotation follows a manual procedure.

Get Help

• Teams: #digital-cpp-support
• Service Now: Open a ticket